add pinocchio spl-token-minter example#600
Conversation
2819844 to
383287d
Compare
Greptile SummaryThis PR adds a Pinocchio implementation of the
Confidence Score: 5/5Safe to merge — all instruction logic, CPI construction, and test assertions are correct. The program logic, Borsh serialization, CPI account layouts, and LiteSVM tests are all correct. The deploy scripts reference a mismatched filename, but this is a pre-existing pattern across sibling pinocchio examples and does not affect the build-and-test path used by CI. The deploy script in package.json and cicd.sh reference program.so instead of the actual cargo output name, but this does not affect testing. Important Files Changed
Sequence DiagramsequenceDiagram
participant Client
participant Program as spl-token-minter<br/>(Pinocchio)
participant System as System Program
participant Token as SPL Token Program
participant Metadata as Metaplex Token<br/>Metadata Program
participant ATA as Associated Token<br/>Account Program
Note over Client,ATA: Create instruction (discriminator = 0)
Client->>Program: Create(name, symbol, uri)
Program->>System: "CreateAccount(mint, 82 bytes, owner=Token)"
Program->>Token: "InitializeMint2(decimals=9, mint_authority=payer)"
Program->>Metadata: "CreateMetadataAccountV3(DataV2, is_mutable=false)"
Metadata-->>Program: OK
Program-->>Client: OK
Note over Client,ATA: Mint instruction (discriminator = 1)
Client->>Program: Mint(quantity)
Program->>ATA: CreateIdempotent(payer, mint)
ATA-->>Program: ATA created or already exists
Program->>Token: "MintTo(mint, ata, mint_authority=payer, amount)"
Token-->>Program: OK
Program-->>Client: OK
Reviews (6): Last reviewed commit: "spl-token-minter pinocchio: use official..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| try { | ||
| mkdirSync(outputDir, { recursive: true }); | ||
| // Point the Solana CLI at mainnet, where the canonical program lives. | ||
| execSync("solana config set -um", { stdio: "inherit" }); |
There was a problem hiding this comment.
postinstall mutates the global Solana CLI config
solana config set -um permanently sets the user's active cluster to mainnet-beta in ~/.config/solana/cli/config.yml. Any developer who runs pnpm install in this directory while working against devnet or localnet will silently have their Solana CLI endpoint changed. solana program dump accepts a --url flag (--url mainnet-beta or --url m), which would fetch from mainnet without touching the global config.
There was a problem hiding this comment.
Fixed in dd291b9. Switched to a per-command solana program dump -um <id> and dropped the global solana config set -um, so postinstall no longer mutates the developer's ~/.config/solana/cli/config.yml. This mirrors the pattern already used in the sibling pda-mint-authority example.
| MintTo { | ||
| mint: mint_account, | ||
| account: associated_token_account, | ||
| mint_authority, | ||
| amount: quantity, | ||
| } | ||
| .invoke()?; |
There was a problem hiding this comment.
mint_authority == payer invariant is not asserted
MintTo requires its mint_authority to be a signer. Here mint_authority (account index 1) is declared as a non-signer ([]) in the instruction — the CPI works only because the payer's address is passed for both slots and the payer signs the transaction. If a caller provides a genuinely different mint_authority key, the SPL Token program rejects the CPI with an opaque "missing required signature" error instead of a clear program-level message. The same applies to create.rs. For an educational example a quick equality check would make the design intent explicit and produce a cleaner error for learners who experiment with different account layouts.
There was a problem hiding this comment.
Intentional for this example. It models the canonical "payer is the mint authority" flow: the same key fills both the payer and mint_authority slots, and since the payer already signs the transaction the MintTo/InitializeMint CPIs satisfy the signer requirement — which is why mint_authority is marked non-signer ([]) here. The SPL Token program is the authority on that invariant and enforces it, so an added equality check would be redundant and would diverge from the anchor example this port mirrors. Happy to add an explicit assert if you'd prefer it for teaching clarity.
| function readTokenAmount(data: Uint8Array): number { | ||
| const buffer = Buffer.from(data); | ||
| return buffer.readUInt32LE(64) + buffer.readUInt32LE(68) * 4294967296; // 2^32 | ||
| } |
There was a problem hiding this comment.
readTokenAmount silently loses precision for amounts above 2^53
The high-word multiplication buffer.readUInt32LE(68) * 4294967296 uses JavaScript's number type, which only holds integers exactly up to 2^53. Token amounts are stored as raw u64 units: 150 tokens at 9 decimals = 1.5 × 10^11, well under 2^53 and safe here. But if a future test mints a much larger amount, the assertion could silently pass with a wrong value. The u64le helper already acknowledges this ceiling; readTokenAmount should carry a similar comment, or the check should use BigInt arithmetic.
There was a problem hiding this comment.
Fixed in dd291b9 via your suggested alternative — added a comment mirroring the u64le encoder, documenting the deliberate es6/no-BigInt design and the exact-below-2^53 guarantee (the 150-token mint asserted here is well within range). Kept number for symmetry with the encoder rather than introducing BigInt on only the decode side.
…t readTokenAmount es6 range
dd291b9 to
c6690d5
Compare
|
@Perelyn-sama @dev-jodee — rebased onto latest main (picks up the ASM sbpf/Solana pin from #625), CI is now fully green. Ready for review whenever you have a chance 🙏 |
Move the async bankrun setup out of the `describe` callback and into a
`before` hook so Mocha collects the `it` blocks (an async `describe` body
registers tests after the suite is already collected, so nothing ran).
With the test now executing, replace `Rent::try_minimum_balance` with the
integer rent formula: its floating-point exemption-threshold path emits an
opcode the bankrun VM rejects ("unsupported BPF instruction"). Matches the
create-token example.
Apply the kit + litesvm template from the mint-close-authority example: build and sign transactions with @solana/kit and run them on litesvm, dropping @solana/web3.js and solana-bankrun entirely. PDAs (metadata, ATA) are derived with getProgramDerivedAddress; the Metaplex Token Metadata program is still dumped from mainnet by prepare.mjs and loaded into LiteSVM via addProgramFromFile (litesvm bundles only the SPL programs). - deps: drop @solana/web3.js + solana-bankrun, add litesvm; pin @solana/kit to ^6.10.0 (litesvm's kit major) so there is a single kit in the tree - tsconfig: bump typescript to ^5 and lib to es2022+dom (kit's types), add @types/node; the suite is type-clean under tsc --noEmit
|
Applied the |
Applies dev-jodee's solana-foundation#624 review refinements on top of the kit + litesvm test: - program: compute rent with Rent::get()?.try_minimum_balance(MINT_SIZE)? instead of the integer-math workaround (only needed to dodge the f64 opcode the old bankrun VM rejected; litesvm runs the real syscall). - test: source the token, associated-token and system program ids from the official @solana-program/token and @solana-program/system packages, and read the minted amount with getTokenDecoder().decode(...).amount instead of a raw byte offset. Token Metadata has no official @solana-program client, so its id stays hand-rolled. - tsconfig: moduleResolution bundler for the packages' subpath exports. Verified locally: cargo build-sbf + ts-mocha -> 2 passing, tsc --noEmit and biome clean, frozen-lockfile OK.
|
Applied the same refinements @dev-jodee asked for on #624 (now merged):
|
2 participants
Adds a Pinocchio implementation of
tokens/spl-token-minter, continuing the Pinocchio token-examples lane aftertransfer-tokens(#596),escrow(#598), andcreate-token(#599).What it does
Two instructions, matching the
anchorandnativeoptions:Notes
0= Create,1= Mint), matching the Borsh enum variant index used by thenativeexample.CreateMetadataAccountV3CPI is built by hand (rawInstructionView/cpi::invoke) — the same approach as add pinocchio create-token example #599.token_metadata.sofixture via apostinstallscript, like theanchorexample.nativeexample.Files
tokens/spl-token-minter/pinocchio/(program + bankrun test)Cargo.toml(workspace member),README.md(pinocchio link),Cargo.lock